由後端產生頁面,通常採用 MVC(Model-View-Controller)架構,由後端伺服器來產生完整的 HTML 頁面。通常會使用 Ruby on Rails 或 Flask 等後端框架實作。後端不僅處理資料邏輯,還生成 View 來展示頁面內容。
優點:
缺點:
CSR (Client-Side Rendering) 主要是為了解決傳統 SSR 的維護問題,透過前後端分離來改善開發流程。後端專注於提供 API 資料,前端則負責渲染 UI 並管理應用邏輯。
隨著應用程式的複雜度提高,處理路由及狀態管理變得困難。這時候 React 等前端框架就派上用場,特別適合建構單頁式應用 (SPA),由前端處理所有路由和狀態的更新,適合需要即時更新的動態應用程式。
優點
缺點
為了解決 CSR 帶來的 SEO 問題,出現了幾種解決方案:
針對搜尋引擎與社交媒體顯示不同內容:
透過伺服器端渲染特定內容,只在搜尋引擎或社交媒體上顯示符合 SEO 標準的 HTML 頁面。當請求是一般用戶時,則可以返回由 JavaScript 渲染內容。雖然解決了部分 SEO 問題,但由於和使用者的內容不一致,這種方法有可能影響 SEO 分數。
Pre-rendering:一種將動態內容預先渲染成靜態 HTML 的技術,在網站建構的過程中,利用伺服器端的工具生成靜態的 HTML 頁面。
React 引入了 SSR,使我們可以在渲染初始 HTML,並在客戶端進行 Hydration。除了保持了傳統 SSR 的優勢,還增加了互動性。這部份通常會使用 SSR 的框架實作,像是 Next.js。
最早的 SSR Hydration 是對整個頁面進行的,但隨著需求的變化,出現了多種優化方式。
頁面上的每個元件分別去做 Hydration,而不是整頁一起做 Hydration,會是由上而下的方式。
這部份就是昨天文章中提到的,React 18 結合 Selective Hydration,可以讓頁面中的某些優先區塊先進行 Hydration,次要部分則稍後處理。
除了 SSR 與 CSR,還有幾種適合不同場景的渲染策略:
在 build time 時就將所有頁面預渲染成靜態 HTML,通常用在不頻繁更新的內容。
結合 SSG 和 SSR,適合部份內容需要不定時更新的網站。當伺服器接到請求發現沒有對應的靜態頁面時,就會觸發 SSR,並將頁面渲染的結果快取。開發者可以設定每個頁面的 revalidate 時間,當伺服器收到請求且超過 revalidate 時間時,會先回傳快取版本並重新渲染頁面。
除了上述渲染方式,其他框架也提出了不同的渲染策略,例如 Qwik 的 Resumable 或 Astro 的 Island architecture。除此之外,還有之後會介紹到的 Server Components 的概念。最主要還是根據使用情境去選擇合適的渲染方式,打造出更好的使用者體驗。
參考資料:
https://blog.huli.tw/2023/11/27/server-side-rendering-ssr-and-isomorphic/
https://techblog.funliday.com/2020/10/14/%E5%9C%A8-ModernWeb-2020-%E5%88%86%E4%BA%AB%E7%9A%84%E3%80%8Cpppr-%E8%A7%A3%E6%B1%BA-JavaScript-%E7%84%A1%E6%B3%95%E8%A2%AB%E6%90%9C%E5%B0%8B%E5%BC%95%E6%93%8E%E6%AD%A3%E7%A2%BA%E7%B4%A2%E5%BC%95%E7%9A%84%E5%95%8F%E9%A1%8C%E3%80%8D/
https://www.patterns.dev/react/progressive-hydration